Hi
Thank you for the new LED driver :) Looks good to me and can be merged. Just one suggestion: modifying that single line in LedDevice.cpp won't change anything about ftdi support, so I'd rather put it off until the next iteration of refactoring this key component if it is not necessary and is not related to the new feature.

Have you tried bit banging to control the Neopixel LEDs? In theory at least 4*800kHz clock would be needed and then:
coding 0 bit => one high, three lows
coding 1 bit => three high, one low
and then reset pulse at the end: low signal for 80(sk6812)-300(ws2812b)us. But this is just a theory, in practice the result depends on how stable the timings will be provided by the device.

Hi Thank you for the new LED driver :) Looks good to me and can be merged. Just one suggestion: modifying that single line in LedDevice.cpp won't change anything about ftdi support, so I'd rather put it off until the next iteration of refactoring this key component if it is not necessary and is not related to the new feature.

Have you tried bit banging to control the Neopixel LEDs? In theory at least 4*800kHz clock would be needed and then: coding 0 bit => one high, three lows coding 1 bit => three high, one low and then reset pulse at the end: low signal for 80(sk6812)-300(ws2812b)us. But this is just a theory, in practice the result depends on how stable the timings will be provided by the device.

yep, I had similar idea about neopixel implementation, shouldn't be quite complicated. I'll try to implement, maybe will find someone who's willing to test it :) Btw I've removed change in LedDevice and overloaded start method in ProviderFtdi instead :) I still don't get that close in start logic

Hi @awawa-dev, I've implemented ws2812 support

Great 👍 Did you test it on larger LED strips? Similar sk6812 SPI driver doesn't work for my LED strip that's why I suggested approach that is used e.g. by Neopixelbus library (fixed not adjustable clock that is set to multiply of Neopixel frequency, a bit different bit encoding) but not sure if it was caused by the Rpi SPI limitation/configuration.

I'd love to test on larger led strips, but my ws2812 test setup is made of a single led, there's not much I can do about it.

Ambilight FT232H implementation.
Hello,
I've been following this project by @nurikk on Discord from the beginning, and I was glad someone came up with such a brilliant idea. I have therefore made myself smart, and I was firmly convinced that a lot of potential in such a FTDI developer board. I ordered the board at Amazon “FT232H USB-to-JTAG-UART/FIFO-SPI / I2C-Module, multifunction module with three pin headers”. Since @nurikk had only Apa102 integrated, I asked whether this would also be possible for SK6812RGBW. The implementation followed promptly and could do a whole series of test.
The board was immediately recognized by my LG webOS 3.9 as FTDI USB Serial Device. With the new HyperHDR loader build from @nurikk, I could start right away. Under controller type Sk68_12ftdi, set RGB byte to GRB and baud rate to 3200000. Since the color calibration of WLED was not implemented at the beginning, I tested a lot and the best results were under “Subtract minimum, custom” with R120, G100 and B160. You can adjust quite a lot, so everyone can make his individual adjustment. The only drawback was the brightness level.
There was no option to reduce it anywhere. The whole thing outshines and overdrives everything.
After consultation with @nurikk, the “White balance correction” from WLED was installed, which allows the use of the dual function (RGB+W) of the SK6812RGBW, as well as brightness delimitation function. The function for Dual is called “Wled auto”.
Moreover, you can still make color corrections in HyperHDR itself until the desired result is achieved.
These new WLED implementations have helped to ensure that nothing more stands in the way and the project FTDI Ambilight a real alternative to WLED due to the simple wiring and direct USB control. Clearly everyone must decide for themselves, but for those who do not have a good WLAN or LAN possibility, this is the better choice. This runs as fast and reliable as @awawa's HyperSerial. Great job by @nurikk, thanks for this.

Hint: there is a white channel algorithm in HyperSerialEsp8266/ESP32/HyperSPI that in my opinion outperforms this algos from WLED and also allows custom settings. And it's also easy to implement.

That would be fantastic, of course, if it's possible.

Hi,
@nurikk, you did a great job again.
I just tested the new HyperHDR build, with “Hyperserial neutral white” color algorithm at a brightness limit of 120 from 255, HDR global off, and it works as it should. I made a small video for comparison with the “Wled auto” algorithm. Personally think that “Wled auto algorithm” brings more vivid colors and “Hyperserial neutral white” color algorithm has finer gradation. Either way, there is the right setting for everyone to choose from. But this is just my visual impression.

I'm hoping to get the FT232H (BTW and 100M logic analyzer and oscilloscope) next month so I can test it out.

I'm hoping to get the FT232H (BTW and 100M logic analyzer and oscilloscope) next month so I can test it out.

Haha, someone broke the piggy bank 😀 congratulations on getting new hardware! 🤩

I'm hoping to get the FT232H (BTW and 100M logic analyzer and oscilloscope) next month so I can test it out.

Hello, I hope that someday, when you have tested everything, you will integrate the FTDI implementation of @nurikk in your release version.

Still I prefer using auto discovery when it handles almost 100% cases without forcing user to specify a unnecessary path. It's different situation than e.g. configuring path for SPI devices which provide no feedback if the device is present at the path or not which may mislead auto-discovery, ftdi reports only valid device. Please revert that commit.

Hello, is there any chance to implement the Hyperion FTDI for Windows?

Yes, I fixed the windows build. It detects devices and tries to open in "auto" mode (selecting a specific device didn't work before). But there are two main problems: libusb has nasty requirements when it comes to accessing physical devices on Windows (non-root users have a similar problem on Linux, but at least there is a workaround for that OS) and brew doesn't provide backwards compatible libftdi /libusb libraries for 10.15. And many Apple devices continued to use this version of macOS without being able to upgrade to 12.x.

Hello, @awawa-dev and @Nurrik
Thanks for the implementation of the FTDI Board in HyperHDR for different platforms. Would be very happy who this is implemented for Windows and would like to test on a Windows PC. This is very interesting for most PCs gaming gamers who would get a good cheap hardware without many bells and whistles for LEDs. I already have WLED/ESP running with Hyperion Screen Capture along with HyperHDR successfully tested on Windows PC.

Hi @nurikk
Finally I got the necessary equipment and found a moment of free time to test. Since libusb on Windows requires the installation of a customized libusbk driver, I ran tests on Linux based on your version before my commit. It didn't work for the pi user, I didn't want to fiddle with udev rules so unfortunately I had to switch the service to root. To begin with sk6812 RGBW:

The frequency is a bit too high from the ideal 800KHz, but the timing are the most correct for sk6812 RGBW.

Then ws2812b:

It's worse here. The frequency is also a bit too high, but it's not a problem. ws2812b has been featured in several revisions over time, the recommended timings have changed but the only critical change was the increase in reset time from 50us to about 280-300us in the latest revisions which broke some ws2812b support libraries at the time. The pulse timing of the bit was backwards compatible regardless of what the manufacturer recommended in the documentation. For ws2812b, practical tests showed that high-time of encoded 1 should be at least 625ns(source), while here we have timings 610ns identical to sk6812b, which will most likely end up with problems (flickering) for ws2812b depending on their version.

Do you know if libftdi was replaced with a proprietary API from the FTDI manufacturer, wouldn't that solve the permissions issues on all systems? The ftdi library doesn't need to be distributed or included in the build if it will be loaded dynamically: a header file is enough.

Hi there! I'd love to try this out. Is it going to work with ws2801? I have one spare lying around..

Hi there! I'd love to try this out. Is it going to work with ws2801? I have one spare lying around..

Since the WS2801 LED is an SPI 3 channel IC with 2.5kHz and has different parameters than the Apa102 and WS2812 Neo-Pixel and the SK6812 RGBW 5050 IC respectively, which have completely different clock frequencies, will not work here. It is necessary that @nurikk also integrates the WS2801 in drivers.

Too bad :(. Thanks for the detailed answer!

@nurikk

Hi,
The Hyperion loader brings HyperHDR version 20.0.0.0beta1 to our LG. Unfortunately, your FTDI implementation is not included.
Is it possible to publish the FTDI in the new version?

@nurikk

Hi, The Hyperion loader brings HyperHDR version 20.0.0.0beta1 to our LG. Unfortunately, your FTDI implementation is not included. Is it possible to publish the FTDI in the new version?

hey @satgit62 I just build latest version https://github.com/nurikk/hyperhdr-webos-loader/actions/runs/8036974919

@nurikk
Hi, The Hyperion loader brings HyperHDR version 20.0.0.0beta1 to our LG. Unfortunately, your FTDI implementation is not included. Is it possible to publish the FTDI in the new version?
hey @satgit62 I just build latest version https://github.com/nurikk/hyperhdr-webos-loader/actions/runs/8036974919

Thank you very much, @nurikk, I've managed that too. I'm already looking forward to the further development.

@nurikk
Hi,
Do you know why on my self compiled version of your FTDI-branch I have to type in terminal ln -s /lib/libudev.so.0.13.1 /media/developer/apps/usr/palm/services/org.webosbrew.hyperhdr.loader.service/hyperhdr/libudev.so.1 to start HyperHDR daemon?
Is a reference/symlink to the libudev not made automatically?
EDIT: even with your version, I have to execute the command in Terminal. (webOS 3.9.2) If I install the regular version via Homebrew Channel, I don't have to do this.

@satgit62

Do you know why on my self compiled version of your FTDI-branch I have to type in terminal ln -s /lib/libudev.so.0.13.1 /media/developer/apps/usr/palm/services/org.webosbrew.hyperhdr.loader.service/hyperhdr/libudev.so.1 to start HyperHDR daemon?

It's because (e)udev was ~recently enabled in the default buildroot-nc4 config (openlgtv/buildroot-nc4@5696b70), and things that link against our libudev get a reference to libudev.so.1. Before eudev was enabled, packages would detect that libudev was unavailable, disable the code that depends on it, and not try to link against it.

We can't just switch to an older eudev with libudev.so.0, since webOS 4.0+ has libudev.so.1. There are various workarounds though: for example, you can build br-nc4 with eudev disabled. You could also try deleting arm-webos-linux-gnueabi/sysroot/usr/lib/pkgconfig/libudev.pc etc.

This doesn't affect the build on Homebrew Channel because it's built using the hyperhdr-webos-loader build workflow, which uses a br-nc4 version from 2022 (before eudev was enabled).

@satgit62

Do you know why on my self compiled version of your FTDI-branch I have to type in terminal ln -s /lib/libudev.so.0.13.1 /media/developer/apps/usr/palm/services/org.webosbrew.hyperhdr.loader.service/hyperhdr/libudev.so.1 to start HyperHDR daemon?

It's because (e)udev was ~recently enabled in the default buildroot-nc4 config (openlgtv/buildroot-nc4@5696b70), and things that link against our libudev get a reference to libudev.so.1. Before eudev was enabled, packages would detect that libudev was unavailable, disable the code that depends on it, and not try to link against it.

We can't just switch to an older eudev with libudev.so.0, since webOS 4.0+ has libudev.so.1. There are various workarounds though: for example, you can build br-nc4 with eudev disabled. You could also try deleting arm-webos-linux-gnueabi/sysroot/usr/lib/pkgconfig/libudev.pc etc.

This doesn't affect the build on Homebrew Channel because it's built using the hyperhdr-webos-loader build workflow, which uses a br-nc4 version from 2022 (before eudev was enabled).

@throwaway96 Hi, thanks for the explanation, so I will delete the libudev.pc from arm-webos-linux-gnueabi/sysroot/usr/lib/pkgconfig/ and see if the daemon starts then.

@nurikk
Hi, The Hyperion loader brings HyperHDR version 20.0.0.0beta1 to our LG. Unfortunately, your FTDI implementation is not included. Is it possible to publish the FTDI in the new version?

hey @satgit62 I just build latest version https://github.com/nurikk/hyperhdr-webos-loader/actions/runs/8036974919

Hi @nurikk,
Since HyperHDR is reaching the stable stage and v20.0.0.0 is running very well, I ask if you would also include this in your repository for FTDI. The latest 20.0.0.0beta2 is still working fine, but it would be nice if FTDI users can also enjoy the new version.

Since the LED driver model will soon be significantly simplified in HyperHDR, I can add these changes and make the appropriate modifications myself. At least when it comes to SPI. In the case of Neopixel, I still have doubts about timings.

BTW, in general, the approach to emulating Neopixel using devices designed for protocol SPI is wrong or at least prone to various vulnerabilities. Therefore it doesn't work well eg. when using SPI in RPi for Neopixel LEDs. The source is the nature of SPI and the many variants of the protocol. Let me give you the simplest example.
Here the emulation works correctly:
SPI is OK (3 bit 110)
Neopixel is OK (pulse length on the upper data axis let's say x ns)

And here the emulation does not work OK, but SPI is still within the limits allowed by the protocol. This may occur, for example, in the event of emitter overload or its buffer underrun. It may just disable the SPI clock for a while until the data is ready.
SPI is still OK (3 bit 110)
Neopixel is not OK (pulse length on the upper data axis could be even n * x ns)

Since the LED driver model will soon be significantly simplified in HyperHDR, I can add these changes and make the appropriate modifications myself. At least when it comes to SPI. In the case of Neopixel, I still have doubts about timings.

BTW, in general, the approach to emulating Neopixel using devices designed for protocol SPI is wrong or at least prone to various vulnerabilities. Therefore it doesn't work well eg. when using SPI in RPi for Neopixel LEDs. The source is the nature of SPI and the many variants of the protocol. Let me give you the simplest example. Here the emulation works correctly: SPI is OK (3 bit 110) Neopixel is OK (pulse length on the upper data axis let's say x ns)

And here the emulation does not work OK, but SPI is still within the limits allowed by the protocol. This may occur, for example, in the event of emitter overload or its buffer underrun. It may just disable the SPI clock for a while until the data is ready. SPI is still OK (3 bit 110) Neopixel is not OK (pulse length on the upper data axis could be even n * x ns)

Yes, you are right, that is a good argument. I also belong to the faction that looks for perfection. The HyperSerialPico, like the HyperSerial, plays in the first league, but there are still people who are not looking for perfection, but for very simple solutions. In this case, FTDI comes first because of its handling under webOS. Those who use FTDI devices are happy to accept that not everything works perfectly.